Return to doc.sitecore.com

  Typical Work Cycle
Prev

If you are a developer, your typical work cycle may look like this:

  1. Check-out the source code you need for the project from the Source Control System. Create and modify content Items in the Dirty database on the server.

    The source code version control is performed in the common way 

    Continue working with the Dirty database until you’ve finished your debugging and testing procedures. Version control cannot be implemented on the Dirty database to the full, as long as all developers may create/modify Items programmatically at the same time.

  2. Prepare the content which needs to be transferred to the Clean database. It may be required to ask other developers not to edit the content in the Dirty database while you prepare and test the package.

  3. Check in the code (The changes should appear in the source code repository first and then may be released to the main server).

  4. Backup the Clean database.

  5. Update the Clean database on the Development server using the Sitecore installation on the server.

  6. Send a broadcast note to other members of the team saying that some items were added/modified. Point to the package you’ve created (optional).

  7. Another developer may now perform actions 1 and 2 and start working locally.

1.  Caching Issue

Sitecore V5 implements cache for reading. When several Sitecore installations point to the same databases (Dirty databases in our case), the developers may see invalid content. This is caused by the fact that caches (as well as sessions) are handled separately for each installation.

Every code recompilation causes site restart, which clears the cache. Code is recompiled quite often during the development process, that’s why the problem described above may not show up very often. But it may be really severe when several developers install packages simultaneously or create items programmatically.

That’s why the Clean database should only be modified with the Development server Sitecore installation. For instance, when several packages are installed by different users simultaneously within one Sitecore installation, package installations are queued and no database breach occurs.


Prev